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ABSTRACT 


The  U.S.  Navy  is  undergoing  a  major  Command  and  Control  (C2)  transformation  to  meet  changes  in 
its  operational  commitments  and  to  ensure  that  necessary  operational  information  (12)  is  delivered  to 
the  “right  person,  at  the  right  time,  and  in  the  right  way.”  Almost  a  decade  after  the  terrorist  attacks 
on  9-1 1 ,  Navy  missions  have  expanded  to  include  such  unconventional  warfare  areas  as 
counterterrorism,  counterinsurgency,  information  operations,  security  cooperation,  humanitarian 
relief,  and  civil-military  operations.  To  meet  these  additional  missions,  the  Navy  increasingly  needs  to 
interoperate  with  other  U.S.  military  services,  U.S.  governmental  agencies,  and  a  diverse  list  of 
international  partners.  In  this  new  environment,  Information  and  Intelligence  (12)  have  become  core 
war-fighting  enablers. 

The  Command  and  Control  Rapid  Prototyping  Continuum  (C2RPC)  is  a  new  initiative  designed  to 
produce  enhanced  operational  concepts  and  capabilities  and  establishes  a  technology  readiness 
venue  for  piloting  new  C2  capability  increments  at  selected  operational  commands.  C2RPC  is  a 
jointly-funded,  cooperative  effort  spearheaded  by  the  Office  of  Naval  Research  (ONR)  and  Program 
Executive  Office  for  Command,  Control,  Communications,  Computers,  and  Intelligence  (PEO  C4I),  in 
cooperation  with  Commander,  U.S.  Pacific  Fleet  (COMPACFLT). 

COMPACFLT  proposed  that  ONR  bring  new  technologies  and  ideas  that  advance  the  “Art  of  C2”, 
to  COMPACFLT  for  evaluation,  validation,  and  refinement.  COMPACFLT  offered  to  provide  access 
to  the  Command’s  resources  and  staff  to  validate  the  C2  technologies  and  to  ensure  that  operational 
concepts  were  tested  with  realistic  data,  in  an  operational  context.  PEOC4I  would  ensure  that  the 
technology  being  developed  would  meet  future  operational  requirements  and  assist  with  the  transition 
of  the  new  technology  to  a  pre-selected  C2  program  of  record  (POR).  The  result  is  that  C2RPC  is  the 
first,  from  the  ground  up,  services  architecture  application  designed  to  run  on  a  shore  based  "cloud" 
infrastructure  or  from  a  new  Consolidated  Afloat  Networks  and  Enterprise  Services  (CANES) 
infrastructure.  This  provides  the  opportunity  for  C2  and  ISR  to  operate  with  an  autonomous  afloat 
capability  when  needed,  with  an  ashore  high  performance  computer  and  network  infrastructure 
augmentation  when  available. 

This  paper  is  comprised  of  two  related  sections.  The  first  section  presents  the  new  C2  strategy 
and  describes  the  capability-related  C2  prototype  components  being  developed  using  an  innovative 
experimentation  methodology  undertaken  within  the  Navy  Research  and  Development  (R&D) 
environment,  and  at  COMPACFLT,  to  rapidly  mature  new  capabilities.  The  second  section  describes 
the  Rapid  Integration  and  Test  Environment  (RITE)  employed  to  ensure  that  new  technologies  are 
successfully  transitioned  to  future  C2  programs  of  record  (POR)  in  a  near-continuous  availability  to 
meet  the  need  for  rapid  technology  change. 


INTRODUCTION 

The  U.S.  Navy  is  undergoing  a  major  IT  transformation  to  meet  changes  in  its  operational 
commitments  and  to  ensure  that  necessary  operational  and  intelligence  information  is  delivered  to  the 
“right  person,  at  the  right  time,  and  in  the  right  way.”  Naval  missions  have  expanded  to  include 
historically  non-traditional  mission  areas  such  as  counterterrorism,  counterinsurgency,  civil-military 
operations,  information  operations,  security  cooperation,  and  humanitarian  relief. 

The  Program  Management  Warfare  Office  for  Command  and  Control  (PMW  150)  is  embarking  on 
a  new  strategic  initiative  focused  on  dramatically  changing  the  functional  capabilities  of  the  Navy’s 
Maritime  C2  systems,  while  fundamentally  changing  its  software  development  and  delivery  processes 
(e.g.  an  “IT  box”).  PMW  150  is  using  C2RPC  to  deliver  the  strategic  initiative.  This  new  C2  strategy  is 
codified  in  the  Naval  Warfare  Publication  3-32  on  “Maritime  Operations  at  the  Operational  Level  of 
War  (OLW)”,  reference  (a)  and  the  Navy  Planning,  Naval  Warfare  Publication  (NWP)  5-01,  reference 
(b).  An  overview  of  the  OLW  is  provided  below  as  context  for  the  initial  C2RPC  prototype 
development. 
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NAVY  COMMAND  AND  CONTROL  STRATEGY 


The  goal  of  C2  is  to  maintain  alignment  and  provide  status  on  the  progress  of  the  command  plan. 
Current  Navy  C2  systems  simply  provide  “Who  and  Where”  information  to  battle  commanders 
situational  awareness.  In  order  to  meet  changing  mission  areas  and  to  be  interoperable  with  other 
operational  organizations,  C2  systems  need  to  fulfill  OLW  requirements  and  provide  timely  What. 
Whery  Why,  and  How  information,  in  addition  to  Who  and  Where.  Warfare  requires  more 
decentralized  decision-making  but  an  increased  need  to  centralize  situational  awareness. 

Mission  management  is  the  method  for  achieving  and  exercising  C2  functions  at  the  OLW  and 
below,  and  can  be  defined  as: 

•  Planning,  executing  [directing,  monitoring]  and  assessing  achievement  of  the  intended 
purpose  of  a  mission;  and 

•  Managing  multiple  missions  while  continuing  to  prioritize  available  resources,  targets,  and 
objectives  to  mass  activities  in  time,  space,  and  purpose  at  the  decisive  times  and  places. 

In  concert  with  NWP  3-32,  PMW  150’s  mission  is  to  emphasize  and  build  the  means  for  naval 
OLW  Commanders  and  subordinate  Commanders  to  effectively  deploy  personnel  and  equipment 
through  the  use  of  a  set  of  requisite  tools  that  enable  the  Navy  command  structure  to  plan,  execute, 
monitor,  and  assess  its  diverse  mission  requirements.  The  scope  of  this  objective  covers  not  only  the 
primary  elements  of  PMW  150’s  product  line  (C2  Planning  &  Decision  Making,  Situational  Awareness, 
and  Combat  Support)  but  also  includes  the  intersection  with  capabilities  provided  across  PEO  C4I 
including:  Intelligence,  Surveillance,  and  Reconnaissance  (ISR),  as  well  as  select  computing  and 
Enterprise  services  of  Joint  C2  programs. 

Command  and  Control  Rapid  Prototyping  Continuum  (C2RPC)  Implementation 

C2RPC  couples  emerging  science  and  technology  (S&T)  developments,  advanced  prototypes, 
and  experimentation  processes  to  explore  Maritime  Operations  Center  (MOC)  Operational  Level  of 
War  (OLW)  needs  at  COMPACFLT  and  Numbered  Fleet  Commands.  C2RPC  is  serving  as  an 
incubator  for  technology  and  “proofs  of  concept”  to  produce  capabilities  that  can  be  transitioned  into 
future  Command  and  Control  (C2)  PORs. 

C2RPC  addresses  S&T  developments  in  support  of  net-centric  capabilities  that  enable  the  Fleet 
to  be  more  adaptive  to  changing  mission  needs  and  more  agile  in  response  to  changing  adversary 
tactics  and  threats.  C2RPC  is  establishing  baseline  technologies  that  demonstrate  the  feasibility  of 
such  dynamic  C2.  The  core  S&T  challenge  being  addressed  is  how  to  implement  a  distributed 
enterprise  based  on:  (i)  a  services  oriented  architecture,  (ii)  shared  plans/tasks  data  model,  and  (iii) 
distributed  data  services  to  provide  effective  support  to  C2  operations?  Such  an  enterprise  must 
permit  C2  planners  and  decision  makers  across  OLW  and  lower  echelons  to  conduct  and  maintain 
operations  during  disconnected,  interrupted,  and  limited  (DIL)  communications  conditions,  and  must 
support  the  Navy’s  Maritime  C2  paradigm  of  centralized  direction  and  de-centralized  (across  multiple 
echelons)  execution. 

Development  of  C2RPC  follows  the  “build  a  little  -  test  a  little”  philosophy  using  a  series  of 
incremental  capability  “drops.”  The  process  allows  for: 

•  Closer  alignment  of  S&T  investment  to  POR  requirements  increasing  the  probability  of 
successful  transition; 

•  Rapid  and  continual  technology  insertion  (e.g.  continuous  integration); 

•  Continuous  prototype  development  and  experimentation  cycle; 

•  Development  of  individual  smaller  development  components/increments  therefore  reducing 
overall  C2  program  risk. 
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Four  Functional  Pillars 


PMW  150’s  C2  developmental  roadmap  is  built  around  the  four  functional  pillars  of  C2  Mission 
Management  as  shown  in  Figure  1 .  C2RPC’s  technical  architecture  has  been  designed  to  capture 
each  pillar’s  functional  components.  The  four  pillars  are  Planning,  Execution,  and  Assessment; 
Intelligence  and  Collection  Management;  Intelligence,  Surveillance  and  Reconnaissance  (ISR)  Data 
Fusion;  and  Force,  Unit,  Network  Capabilities  and  Readiness.  There  is  an  “invisible”  pillar  in 
C2RPC’s  approach.  This  “invisible”  pillar  is  User  Facing  Services  (UFS)  and  it  is  depicted  in  the 
center  of  Figure  1 .  This  is  where  the  majority  of  the  C2RPC  User  interactions  are  performed. 

It  is  important  to  note  that  PMW  150  is  only  responsible  for  providing  the  functionality  associated 
with  the  Planning,  Execution,  and  Assessment  Pillar  and  the  User  Facing  Services.  Therefore  PMW 
150  must  rely  on  external  organizations  for  the  services  and  data  base  repositories  that  are  resident 
within  their  respective  pillars.  C2RPC  has  established  links  to  the  other  pillars  enabling  operators’ 
access  to  respective  services  and  data  at  a  central  location,  using  a  tailorable  web-based  interface. 
Vice  Admiral  Dorsett’s  (Deputy  Chief  of  Naval  Operations  for  Information  Dominance  (N2/N6))  Vision 
for  U.S.  Navy  Information  Dominance,  reference  (c),  establishes  a  net-centric  operational  approach 
where  “ALL  data  and  information  needs  to  be  universally  discoverable,  transparent  and  accessible”. 
This  approach  is  critical  to  ensuring  that  the  Navy  has  the  ability  to  share  information  seamlessly  with 
other  organizations,  including  international  partners.  C2RPC  relies  upon  the  full  implementation  of 
this  net-centric  approach  for  open  access  to  the  other  pillars. 
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Figure  1.  Functional  Pillars  of  Mission  Management 


The  Capabilities  that  are  developed  by  C2RPC  are  in  support  of  these  four  pillars  plus  the 
“invisible”  UFS  Pillar.  The  first  COMPACFLT  installation  (Drop  1)  in  early  2010  was  built  around  the 
short  list  of  Planning,  Execution,  and  Assessment  Pillar  and  UFS  Pillar  capabilities  shown  in  Figure  2 
and  Figure  3.  In  simplified  terms,  these  Pillars  represent  any  information  about  Plans/tasks,  priority 
missions,  decision  points,  and  readiness.  This  C2  operational  context  provides  the  background  for 
this  paper  and  the  incremental  development  methods  used  for  rapid  development  and  demonstration, 
and  the  additive  nature  of  each  of  the  developed  components.  To  assist  the  reader,  key  C2-related 
acronyms  are  shown  in  Table  1  at  the  end  of  this  paper. 

The  Capabilities  &  Readiness  pillar  provides  related  information  on  Blue  Forces,  their  readiness, 
and  conditions  of  interest  related  to  the  plans  in  progress  or  underway.  The  pillar  leverages  heuristic- 
based  reasoning  to  determine  the  impact  of  aggregated  capabilities.  The  Plan  readiness  information 
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is  displayed  using  an  Ozone  Widget  Framework  (OWF)  composed  “Plans/Execution  Dashboard.”  In 
the  context  of  situation  awareness  (SA)  and  Intelligence,  the  configuration  seeks  to  provide 
relationships  between  the  Intelligence  and  Collection  Management  (CM)  Pillar  and  the  ISR  Data 
Fusion  Pillar.  Those  relationships  result  in  the  capability  to  perform  heuristic  reasoning  on 
intelligence  information. 
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Figure  2.  COMPACFLT  Drop  1 


C2RPC  Incremental  Functionality 

PMW  150  has  adopted  a  component  portfolio  approach  to  C2  system  software  acquisition. 
Incremental  development  is  a  key  element  of  PMW  150’s  system  software  component  strategy  and 
requires  close  collaboration  among  developers,  evaluators,  and  end  users  (Warfighters).  Each 
component  of  capability  provides  a  militarily  useful  and  supportable  operational  capability.  These 
components  are  iterated  over  time  and  delivered  when  mature.  The  system’s  architecture  is 
designed  to  support  these  incremental  deliveries  and  enables  additional  components  to  be  added 
periodically  to  the  core  Navy  C2  architecture. 

Initial  Operational  Capability 

The  focus  of  the  initial  C2RPC  prototype  was  to  provide  C2  planning  functions  to  support  high- 
priority  missions  and  plans  within  the  COMPACFLT  area  of  responsibility  (AOR).  Figure  3  depicts 
this  initial  capabilities  release  set  that  is  planned  for  transition  to  the  Maritime  Tactical  Command  and 
Control  (MTC2)  POR  in  December  2011. 
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Figure  3.  MTC2  Release  One 

The  figure  includes  a  core,  or  “central  capability”  consisting  of  Applications  Support,  Data 
Management  and  Enterprise  Services  abstraction,  that  components  will  be  integrated  to  and  will 
interact  with.  These  core  capabilities  are  shown  in  the  bottom  set  of  boxes  in  Figure  3.  The 
additional  capabilities  align  with  the  four  functional  pillars  discussed  previously  and  are  shown  in  the 
color-coded  boxes.  This  phased  delivery  is  designed  to  add  increased  overall  C2  functionality  over 
time  and  to  gather  user-feedback  to  help  drive  future  capability  development.  The  components  are 
additive  and  the  proven,  operator-validated  capabilities  from  the  collective  set  will,  in  total,  represent 
the  C2  capabilities  as  candidates  for  the  MTC2  acquisition  program.  In  all,  there  are  four  drops 
planned  before  the  “capability  cut-off’,  planned  for  December.  At  that  time  the  aggregate  release  set 
of  capabilities  will  undergo  additional  S&T  funded  development  to  achieve  the  maturity  level  required 
for  a  successful  transition.  Then  during  transition,  the  release  configuration  will  receive  further 
hardening  and  developmental  testing  (i.e.  unit,  regression,  etc)  under  R&D  funding  before  entering  a 
formal  Development  Test  and  Operational  Test  (DT/OT)  program.  It  is  important  to  note  that 
individual  components,  although  based  upon  an  initial  set  of  requested  capabilities  from 
COMPACFLT,  are  dynamic.  The  final  component  functionality  is  a  product  of  the  baseline  Warfighter 
capabilities  and  approved  dynamic  modifications  resulting  from  the  prototyping  process  and  direct 
feedback  from  operational  users.  Therefore,  the  final  capabilities  list  for  transition  may  differ  from 
Figure  3.  The  prototyping  process  will  be  described  in  a  later  section. 

Prototyping  Continuum 

Under  the  C2RPC  initiative,  the  development  and  maturing  of  new  technology  is  ongoing  and  will 
continue  using  additional  S&T  funding  after  the  capability  cut-off  for  Release  One.  Figure  4 
represents  a  listing  of  potential  C2RPC  capabilities  proposed  for  future  prototype  development.  In  the 
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future  drops,  the  objective  is  to  support  operational  units  expanding  from  the  ashore  MOCs  to  the 
afloat  Navy  (e.g.  task  force  (TF)  and  task  group  (TG)  level  ships).  The  final  set  selected  for  MTC2 
Release  Two  will  be  derived  from  the  continually  evolving  set  of  mission  oriented  requirements  and 
maturing  prototypes. 
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Figure  4.  Proposed  Navy  Planning,  Execution  and  Assessment  Services 


C2RPC  PROTOTYPE  DEVELOPMENT  AND  EXPERIMENTATION 
METHODOLOGY 

The  C2RPC  methodology  is  described  in  this  section.  The  C2RPC  prototype  development  and 
experimentation  methodology  was  designed  to  overcome  the  many  challenges  associated  with  the 
transition  of  S&T  experimentation  to  acquisition  programs.  These  shortfalls  have  been  well 
documented  and  highlight  a  historically  poor  record  of  achievement  within  the  Navy.  A  representative 
study  is  that  conducted  by  the  National  Academy  of  Sciences  on  the  Role  of  Experimentation  in 
Building  Future  Naval  Forces,  reference  (d).  In  this  study,  the  committee  focused  on  (1)  doctrine  and 
tactics,  techniques,  and  procedures  and  (2)  fielded  capabilities,  including  acquisition  programs. 
Observations  were  summarized  as  “transitions  are  very  difficult,  and  processes  for  achieving  them 
are  seen  as  poor”,  “owing  in  part  to  budget  pressures  and  to  a  lack  of  processes  for  new  capabilities 
to  compete  with  programs  of  record.”  The  study  further  states  that  “mechanisms  and  processes  for 
transitioning  the  results  of  experimentation  directly  to  the  fleet  or  to  an  acquisition  program  of  record 
are  inadequate  and  they  curtail  the  effectiveness  of  experimentation  in  building  future  naval  forces.” 

National  Defense  Authorization  Act  of  2010  Alignment 


In  2010,  Congress  passed,  and  the  President  signed,  the  National  Defense  Authorization  Act, 
becoming  Public  Law  1 11-84.  This  law  defined  a  new  acquisition  process  for  IT  systems. 
Conventional  DoD  acquisition  processes  were  too  long  and  cumbersome  to  fit  the  needs  of  IT 
systems  that  require  near  continuous  change.  This  process  for  IT-intensive  systems  is  to  be  based 
upon  the  recommendations  provided  in  the  March  2009  Report  of  the  Defense  Science  Board  (DSB) 
Task  Force  on  Department  of  Defense  Policies  and  Procedures  for  the  Acquisition  of  Information 
Technology  (hereafter  referred  to  as  DSB-IT),  reference  (e).  This  report  echoes  the  findings  of  many 
other  studies  in  listing  the  many  issues  surrounding  the  DoD  acquisition  life  cycle  and  specifically 
identified  the  need  for  a  new  acquisition  process.  The  Defense  Science  Board  (DSB)  came  to  the 
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conclusion  that  “there  is  a  need  for  a  unique  acquisition  process  for  information  technology”  (which 
includes  Command  and  Control  systems).  “The  process  must  accommodate  the  rapid  evolution  of 
information  technologies;  their  increasingly  critical  position  within  DoD  warfare  systems,  warfare 
support  systems;  and  business  systems;  and  the  ever  evolving  and  often  urgent  IT  needs  of  the  war 
fighters.”  The  proposed  new  acquisition  process  is  shown  in  Figure  5. 
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Figure  5.  DSB-IT  Recommended  Acquisition  Process  for  Information  Technology 


The  new  process  is  geared  to  delivering  meaningful  increments  of  capability  in  approximately  18 
months  or  less,  and  leverages  the  advantages  of  modern  IT  practices.  Multiple,  rapidly  executed 
releases  of  capability  allow  requirements  to  be  prioritized  based  on  need  and  technical  readiness, 
allow  early  operational  release  of  capability,  and  offer  the  ability  to  adapt  and  accommodate  changes 
driven  by  field  experience.  The  new  process  will  include: 

•  Early  and  continual  involvement  of  the  user; 

•  Multiple,  rapidly  executed  increments  or  releases  of  capability; 

•  Early,  successive  prototyping  to  support  an  evolutionary  approach;  and 

•  A  modular,  open-systems  approach 

The  C2RPC  methodology  has  all  of  the  attributes  and  is  described  below. 

C2RPC  Implementation  Roadmap 

A  notional  C2RPC  Implementation  Roadmap  with  its  various  programmatic  stages  is  shown  in 
Figure  6.  The  graphic  shows  the  relationships  between  the  stages  including  the  planned  transition  of 
new  C2RPC  technologies  to  the  MTC2  POR  after  completing  “Early”  and  “Late”  Stage  prototype 
development  cycles.  The  Roadmap  aligns  with  both  traditional  DoD  Acquisition  Life  Cycle  milestones 
required  in  DoD  Instruction  5000.02,  reference  (f),  and  the  processes  recommended  in  the  DSB-IT 
report. 

C2RPC  Capabilities  Definition 

In  April,  201 1  the  Vice  Chairman  of  the  Joint  Chiefs  of  Staff  (JCS)  announced  at  the  27th  National 
Space  Symposium  that  the  DoD  was  scrapping  the  Joint  Capabilities  Integration  and  Development 
System  (JCIDS)  process  because  it  was  too  slow  and  intends  to  rewrite  the  process  to  allow 
acquisitions  to  be  made  more  quickly  and  at  less  cost.  JCIDS  is  the  formal  DoD  procedure  that 
defines  acquisition  requirements  and  evaluation  criteria  for  all  defense  programs  and  was  not 
responsive  to  the  needs  of  IT-intensive  acquisition  programs  that  require  almost  continuous 
technology  upgrades. 
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Figure  6.  Notional  C2RPC  Implementation  Roadmap 


C2RPC  was  already  employing  a  modified  approach  for  the  identification  and  assessment  of  C2 
capability  objectives  which  linked  members  of  the  S&T  community,  Maritime  C2  Program  Office, 
software  developers  and  end-users  together  in  real-time  to  establish  prioritized  C2  objectives.  This 
C2  independent  product  team  (C2IPT)  consists  of  SMEs  from  ONR,  working  along  with  PMW  150 
and  COMPACFLT.  The  C2IPT  meets  in  periodic  workshops  at  COMPACFLT  Headquarters  to 
identify  and  prioritize  operationally  relevant  C2  objectives.  These  2-3  day  forums  are  held  every  3-6 
months  and  normally  coincide  with  Increment  drops,  so  that  the  users  have  the  opportunity  to  express 
their  provide  inputs  to  the  software  developers  directly.  The  workshops  are  chaired  by  ONR  but 
include  representatives  from  all  stakeholders. 

The  initial  workshop  was  held  June  24  to  26,  2008  where  the  first  set  of  objectives  was 
established,  in  response  to  COMPACFLT  priorities.  These  included: 

•  C2  of  Intelligence  Operations 

•  C2  of  Information  Operations 

•  C2  of  Network  Operations 

•  C2  of  Computer  Network  Protection 

•  Common  Operational  Picture  (COP)  Improvement 

These  agreed  upon  objectives  were  used  to  derive  a  set  of  “capability  gaps”  that  were  prioritized 
for  the  initial  C2RPC  C2  Increment.  The  capabilities  have  since  evolved  and  new  capabilities  have 
been  added  as  a  result  of  experimentation  results  and  early  exposure  to  the  operator  who  provided 
recommended  modifications. 
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To  support  the  requirements  definition,  the  Roadmap,  shown  in  Figure  6,  lists  several 
Requirements  related  documents  that  are  important  to  establishment  of  an  upfront  Technology 
Development  Strategy  and  are  necessary  to  achieve  acquisition  Milestones  and  Build  Decisions  for  a 
POR  like  MTC2.  Even  with  the  modified  approach  to  establishing  the  initial  capability  objectives,  the 
listed  documents  are  needed  to  guide  the  acquisition  activities  and  align  them  with  POR 
requirements.  These  documents  include: 

•  Initial  Capabilities  Document  (ICDj.  As  described  in  the  JCIDS  manual,  reference  (g),  the 
ICD  documents  the  “need  for  a  materiel  approach,  or  an  approach  that  is  a  combination  of 
materiel  and  non-materiel,  to  satisfy  specific  capability  gap(s).”  The  ICD  defines  the  gap  in 
terms  of  functional  area;  relevant  range  of  military  operations;  desired  effects;  time  and 
Doctrine,  Organization,  Training,  Materiel,  Leadership  and  Education,  Personnel,  and 
Facilities  (DOTMLPF);  and  policy  implications  and  constraints.  The  outcome  of  an  ICD  could 
result  in  one  or  more  DOTMLPF  Change  Recommendations  (DCRs)  or  Capability 
Development  Documents  (CDD). 

•  Capabilities  Development  Document  (CDD).  The  Technology  Development  Strategy 
includes  a  description  of  how  the  materiel  solution  is  sub-divided  into  Capability  Increments, 
Releases,  and  Iterations  (Drops).  The  CDD  builds  on  the  ICD  and  provides  detailed 
operational  performance  parameters  necessary  to  complete  the  proposed  systems  design. 
These  requirements  are  prioritized  and  parsed  into  groupings  to  establish  baselines  for  initial 
and  subsequent  releases.  The  objective  of  C2RPC  is  to  develop  and  deploy  the  highest- 
priority  mission  capability  first  and  reduce  the  technical  risk  to  the  POR.  Therefore, 
capabilities  defined  in  the  CDD  are  prioritized  and,  where  appropriate,  grouped  into  a  limited 
number  of  time-phased  releases  that  correspond  to  mission  priorities.  An  agile  approach 
allows  for  the  reprioritization  of  requirements  for  each  iteration  and  release  (and  for  the 
increment  as  a  whole)  based  on  subsets  of  functionality  to  prevent  delay  and  facilitate  rapid 
development  and  deployment. 

•  Capabilities  Deyeioprnent  Plan  (CDP)  -  Release  1  to  Release  (n).  The  purpose  of  the 
Capability  Development  Plan  (CDP)  is  to  serve  as  the  agreement  between  the  Program 
Sponsor,  the  Program/Project  Manager  (PM),  and  the  Acquisition  Decision  Authority  (ADA) 
on  the  activities,  cost,  schedule,  and  performance  boundaries  of  the  work  to  be  performed  for 
the  POR  and  the  artifacts  from  C2RPC  are  used  to  substantiate  the  reduced  risk.  The  CDP 
presents  topics  and  issues,  specific  to  the  acquisition,  that  allow  the  PM  to  clearly  define  the 
“body  of  work”  that  must  be  accomplished  during  each  planned  software  release.  The 
process  in  Figure  6  indicates  that  CDPs  occur  on  a  6-12  month  cycle  and  coincide  with  Build 
Decisions  and  S&T  increment  drops.  Note  that  CDR  release  (r)  1  coincides  with  the 
capability  cut-off  date  and  the  initiation  of  transition  to  the  MTC2  POR. 

C2RPC  Governance 

The  pace  of  technology  change  and  the  increasing  levels  of  complexity  in  C2  systems 
necessitate  a  more  agile  governance  model  for  the  acquisition  of  IT-intensive  systems.  One  of 
C2RPC’s  goals  was  to  enhance  the  project  agility  and  responsiveness  to  technology  change  and  user 
requirements.  C2RPC  wanted  to  establish  a  process  where  the  Combatant  Command  (Warfighter) 
had  authority  to  reprioritize,  add  or  delete  non-key  performance  parameter  requirements  working 
along  with  the  POR  program  sponsor  and  appropriate  milestone  decision  authority.  This  new 
governance  model  allows  the  development  programs  to  more  rapidly  evolve  to  support  changing 
Fleet  needs.  C2RPC  governance  includes  several  different  activities  to  ensure  that  Fleet  inputs  are 
addressed  when  making  programmatic  changes. 


•  Periodic  Workshops.  As  stated  previously,  C2RPC  conducts  Periodic  Workshops  to  develop 
and  validate  new  C2  capability  requirements  and  to  gather  operator  feedback  on  recent 
capability  installations.  The  Workshops  are  2-3  day  forums  and  are  normally  conducted 
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every  3-6  months  coinciding  with  engineer  drops.  The  workshops  are  chaired  by  ONR  but 
include  members  of  the  C2  IPT.  These  workshops  have  been  instrumental  in  establishing 
the  operational  objectives  for  the  incremental  development  and  related  engineering  drops. 
Feedback  from  each  successive  drop  has  been  used  by  the  development  to  further  enhance 
the  C2  capabilities  being  installed. 

•  On-site  Technical  Representative.  Coinciding  with  C2RPC  Drop  1,  ONR  assigned  a  C2RPC 
system  engineer  to  work  on-site  at  COMPACFLT.  The  C2RPC  system  engineer  works  with 
the  operators,  trains  them  on  C2RPC,  gathers  additional  user  feedback  and  interests,  and 
helps  interpret  the  operators’  new  capability  requests  for  C2RPC  deliveries.  This  individual 
interacts  with  COMPACFLT’s  operational  and  technical  personnel  to  document  and  report 
recommended  component  changes  to  the  developer  team.  In  some  cases,  software 
modifications  have  been  done  in  near-real  time  and  the  operator  was  able  to  experience  the 
rapid  response  to  proposed  system  changes.  This  has  helped  to  foster  a  strong  working 
relationship  between  the  developers  and  operators  and  has  reinforced  the  operator’s 
involvement  in  the  development  process.  The  operators  are  actively  engaged  in  providing 
feedback  and  are  committed  to  the  success  of  the  final  set  of  C2  components.  This  feedback 
has  resulted  in  multiple  iterative  improvements  to  upcoming  drops,  with  minor  updates 
occurring  daily  or  weekly. 

•  Software  Change  Requests,  In  addition  to  the  periodic  workshop  and  on-site  technical 
representation,  C2RPC  uses  an  online  Software  Bug  Report  and  Change  Request  tool  (the 
“JIRA”  system)  to  submit  change  recommendations.  A  change  request  is  a  standard  form  for 
documenting  what  needs  to  be  accomplished,  but  does  not  address  how  the  change  should 
be  implemented.  The  JIRA  “tickets”  are  used,  in  addition  to  the  feedback  received  via  the 
other  methods,  by  the  Engineering  Review  Board  (ERB)  to  document  longer  range 
enhancements,  re-prioritize,  and  to  assign  resources  to  the  modifications  or  requested  new 
capabilities. 

•  Engineering.  Review.  Board.  The  Engineering  Review  Board  (ERB)  is  responsible  for 
establishing  the  technical  roadmap  for  C2RPC  as  well  as  setting  the  capability  release  cycle 
(Drops),  prioritizing  the  capabilities  and  fixes,  assigning  technical  resources  within  resources 
constraints  handed  down  by  Management  for  C2RPC.  Additionally,  it  is  responsible  for 
ensuring  the  configuration  control  of  the  various  software  increment  releases  and  ultimately 
determines  the  selection  and  timing  of  the  components  for  migration  from  Early  Stage  -  to- 
Late  Stage  -  to  -nominating  technologies  for  Transition.  Proposed  changes  to  the  C2RPC 
Drops  gathered  either  through  the  workshops  or  the  SCR  process  is  reviewed  by  the  ERB. 
This  board  is  chaired  by  the  C2RPC  Chief  Engineer  (as  designated  by  ONR  and  PMW  150) 
and  includes  representatives  from  each  of  the  four  functional  Pillars  (ISR,  etc)  described 
earlier.  The  ERB  convenes  weekly  to  review  and  adjudicate  C2RPC  technical  and 
engineering  topics.  The  ERB  provides  the  C2RPC  a  level  of  project  flexibility  needed  to  meet 
the  relatively  short  development  cycle.  It  is  necessary  to  have  a  Board  with  this  responsibility 
and  authority  if  the  rapid  prototyping  and  integration  activities  are  to  meet  the  4-6-month 
release  cycles  envisioned  as  part  of  the  IT-intensive  systems  acquisition  process. 

The  ERB  is  empowered  to: 

Establish  capability  requirements  and  prioritization 

-  Approve  proposed  component  changes  submitted  through  SCR  process 

Modify  prototype  requirements  to  meet  operator  needs 

-  Select  the  mature  capabilities  and  propose  them  for  transition 
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Continuous  Prototype  Development 

C2RPC  has  separated  prototype  development  into  two  distinct  stages:  Early  Stage  and  Late 
Stage.  These  stages  are  related  to  overall  technology  maturity  levels  of  the  respective  capability 
components  and  have  separate  S&T  funding  sources.  The  Early  Stage,  designated  for  Advanced 
Technology  Development,  is  funded  by  6.2  and  6.3  budgets,  while  the  Late  Stage,  involving 
Demonstration  and  Validation  experiments  (along  with  approved  prototype  modifications  and 
changes)  conducted  at  COMPACFLT,  is  funded  from  6.3  and  6.4  budgets.  It  is  important  to  note  that 
this  separation  of  stages  supports  the  continual  progression  of  maturing  capabilities  that  are  available 
for  graduation  to  the  next  level  of  development  without  unnecessary  delay.  For  example,  Early  Stage 
capabilities  that  have  reached  an  acceptable  technology  readiness  level  (TRL),  as  described  in  the 
Defense  Acquisition  Guide  (DAG),  reference  (h),  are  moved  to  the  Late  Stage  where  they  undergo 
relevant  operational  experimentation. 
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Figure  7.  C2RPC  and  Technology  Readiness  Levels  (TRLs) 
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Additionally,  as  Late  Stage  capabilities  are  evaluated  at  the  requisite  maturity  level,  they  enter  the 
transition  phase,  where  they  receive  further  capability  enhancements  and  the  software  hardening 
necessary  for  final  transition  to  the  POR.  Lastly,  this  separation  of  development  stages  allows  the 
Early  Stage  to  serve  as  the  incubator  of  new  technology  with  new  prototype  components  being 
initiated  as  additional  requirements  are  identified.  The  capability  components  need  not  adhere  to  pre¬ 
determined  development  cycles  and  independently  move  through  the  development  process.  This 
methodology  allows  the  C2RPC  to  provide  a  “continuum”  of  new  capability  components  that  are  being 
routinely  evaluated  for  transition  to  the  POR. 

Figure  7  depicts  the  different  TRLs  and  indicates  the  separation  of  C2RPC  and  POR 
responsibilities,  including  the  overlapping  transition  of  S&T  to  POR.  The  figure  also  introduces  the 
“progressive”  integration  approach  being  employed  by  C2RPC  to  gradually  introduce  POR 
engineering  processes  to  the  various  release  components  as  they  progress  from  Early-to-Late-to- 
Transition  Stages.  Early  S&T  stages  (e.g.  Applied  Research  and  Advanced  Technology 
Development)  are  often  less  structured  and  therefore  the  prototype,  as  part  of  the  experimentation 
and  maturing  process,  needs  to  incorporate  POR  best  practices  for  such  things  as  software 
configuration  management  and  documentation.  There  is  a  desire  to  minimize  the  number  of 
additional  cost  and  schedule  inhibitors  and  C2RPC  employs  knowledge  management  tools  to 
streamline  the  accumulation  of  necessary  project  documentation. 

Rapid  Integration  and  Test  Environment  (RITE)  for  Continuous  Integration 

The  iterative  nature  of  incremental  component  software  development  and  the  migration  to  net- 
centric  operations  require  a  different  set  of  software  acquisition  processes.  PMW  150  has 
established  the  Rapid  Integration  and  Test  Environment  (RITE)  to  facilitate  needed  C2  testing  and 
integration  process  change.  RITE  is  a  modified  life  cycle  model  for  Navy  C2  software  that  places 
increased  emphasis  on  early  and  frequent  software  testing,  as  well  as  necessary  software 
engineering  practices  at  the  source  code  level.  RITE  provides  an  agile  approach  to  software 
development,  taking  full  advantage  of  technology  advances  and  open  source  models  to  automate 
processes  and  shorten  development  cycles  -  thus  increasing  the  maintainability  of  software 
baselines.  RITE  also  clarifies  software  delivery  requirements,  adding  engineering  structure  to  final 
deliverables  and  reducing  opportunity  for  misunderstanding  between  sponsors,  end-users  and 
developers. 

From  C2RPC,  transition  and  integration  of  new,  adapted,  and  adopted  C2  system  software 
capabilities  and  technologies  will  be  synchronized  into  periodic  C2  Releases  (C2R),  nominally  on  a 
four-to-six  month  cycle.  This  nominal  release  cycle  time  is  subjected  to  business  case  analysis  in 
determining  the  appropriate  period.  It  will  be  constrained  by  the  time  it  takes  to  certify  a  software 
baseline  in  all  of  its  intended  configurations  and  to  train  personnel  to  operate  its  new  features.  As  the 
various  incrementally  developed  capabilities  achieve  the  requisite  maturity  level  (TRL  6-7),  they  will 
individually  be  evaluated  for  integration  into  the  POR. 

The  successful  transition  of  increments  developed  under  the  C2RPC  umbrella  is  critical  to 
achieving  rapid  Navy  C2  system  enhancement.  Therefore,  close  coordination  between  the  Program 
Office  and  the  individual  prototype  developers  as  the  mature  capabilities  near  transition  is  paramount. 
During  the  transition,  the  development  program  must  begin  adopting  and  implementing  the  software- 
development  processes  employed  by  the  POR  while  it  is  effectively  changing  funding  sources  from 
S&T  (6.3A,  6.3B)  to  POR  acquisition  (6.4-6. 5).  The  RITE  processes  and  infrastructure,  as  shown  in 
Figure  8  will  be  used  for  the  transition  of  C2RPC.  Using  the  centralized  repository,  as  the  selected 
capability  increments  reach  the  requisite  TRL  for  transition,  they  will  enter  the  RITE  testing  and 
integration  processes.  These  processes  include  completion  of  a  pre-delivery  qualification  conducted 
by  the  vendor  to  ensure  that  the  prototype  is  ready  to  be  tested.  Upon  satisfactory  completion  of  the 
acceptance  checklist,  the  product  will  undergo  daily  source  code  analysis  and  other  testing  programs 
designed  for  the  capability  being  hardened  and  evaluated. 
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Figure  8.  RITE  Transition  Processes  for  C2RPC  Components 


Hosted  Centralized  Repository 

RITE  hosts  a  software  development  and  transition  environment  to  facilitate  continuous 
development  and  integration.  The  hosted  environment  is  centered  on  an  information  repository  (IR), 
where  all  stakeholders  share  information  and  have  access  to  a  common  set  of  documentation  and 
development  tools.  This  hosted  environment  includes  a  segmented  build  environment  for  each 
developer  to  control  its  individual  source  code,  but  allows  third  party  (public,  with  limited  access) 
sharing  of  libraries  and  associated  tools  that  are  used  across  multiple  developmental  projects.  The 
repository  allows  a  broader  stakeholder  base  to  interact  with  the  components  as  they  progress 
through  the  various  development  and  transition  stages. 

The  services  and  support  that  are  provided  through  the  hosted  environment  include: 


•  Developer  Version  Control 

•  Communication  /  Tool  Support 

•  Quality  Control 

•  Automated  Testing  and  Integration  Environment 

As  shown  in  Figure  9,  the  Central  Repository  is  actually  a  collection  of  three  types  of  repositories. 
The  cardinality  of  each  repository  type  varies,  but  in  the  figure  they  are  each  represented  as  if  they 
are  single  units.  Each  Repository  can  be  accessed  by  the  various  stakeholders  (developers,  testers, 
and  end-users)  using  the  central  configuration  management  system.  The  three  Repositories  include: 

•  Application  [ Developer )  Repositories.  The  most  numerous  repository  type  is  the  developer 
repository.  Each  prototype  development  contractor  has  access  to  its  own  repository  for 
developing  source  code.  These  modules  can  either  be  standalone  applications,  components  of  a 
parent  application,  or  code  libraries  meant  for  use  by  other  products.  By  combining  these 
modules  with  shared  code  and  external  tools  and  for  applying  a  build  process  to  them,  software 
configuration  items  (Cl)  can  be  produced  for  C2RPC  use. 
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Figure  9.  Repository  Management,  Prototype  Development  and  Transition 

•  External  Repository.  The  external  repository  is  a  public,  read-only  Subversion  repository  for  use 
by  all  participating  developers.  Its  purpose  is  to  contain  software  CIs  that  meet  the  following 
criteria: 

They  are  required  for  a  developer  to  create  a  software  product 

They  are  publicly  available  and  free  to  use  (no  proprietary  tools  are  allowed) 

They  are  not  tied  to  a  particular  developer’s  project 

Items  which  would  be  found  in  this  repository  include: 

Compilers  and  interpreters  (JDK,  gcc,  Python,  Perl,  et  at) 

Build  tools  and  frameworks  (ant,  Maven,  ivy,  et  at) 

Integrated  Development  Environments  (IDEs)  (Netbeans,  Eclipse,  eta I) 

External  application  programming  interfaces  (APIs)  and  libraries 

The  external  repository’s  primary  role  is  to  store  all  of  the  3rd-party  tools  needed  by 
developers  to  assemble  and  make  ready  their  development  environment.  Because  this 
repository  is  read-only,  developers  are  not  able  to  populate  it  themselves.  In  order  to  get  the 
necessary  tools,  they  must  send  a  request  to  the  Repository  configuration  management  (CM) 
team,  who  works  with  the  developers  to  place  all  needed  tools  into  the  repository.  This  is 
important  as  the  CM  team  will  be  responsible  for  using  the  developer’s  build  instructions  to 
exactly  replicate  the  software  for  testing  and  eventual  release.  Placing  such  tools  in  one 
location  under  version  control  thus  serves  several  purposes: 

It  ensures  that  a  project  uses  a  well-defined  set  of  3rd-party  tools; 
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It  also  ensures  that  should  the  3rd-party  tools  change,  the  documentation  and 
repository  will  be  updated  to  reflect  the  change; 

Placing  these  tools  (which  usually  are  much  larger  than  the  codebases  they  operate 
on)  in  one  common  location  saves  repository  space  and  allows  sharing; 

It  encourages  developers  to  make  efforts  to  replicate  a  ‘clean’  build  environment. 

•  Common  Component  Repository.  The  common  component  repository  is  a  public,  limited-access 
Subversion  repository  which  contains  libraries  to  be  used  across  multiple  developer  projects.  The 
typical  example  would  be  a  repository  containing  common  interfaces  and  base  functionality  to  be 
used  across  a  set  of  software  products.  The  common  repository,  however,  is  populated  by  code 
written  by  the  developers  and  not  by  external  interfaces  (thus  differentiating  it  from  the  code  in  the 
external  repository). 

C2RPC  Transition  Process 

A  significant  challenge  facing  the  C2RPC  effort  is  transitioning  the  technology  prototype 
components  to  the  MTC2  program  of  record.  The  transition  involves  the  continued  maturation,  and 
hardening,  of  the  final  designated  capability  components  within  Release  One  while  undergoing  a 
change  in  program  funding  from  S&T  to  POR.  This  “hand-off’  is  conducted  in  the  proverbial  “valley  of 
death”  for  new  development  programs  where  the  “initial  funding”  is  often  fully  expended  before 
funding  needed  for  continuity  of  operation  is  received.  There  are  numerous  impediments  to 
successful  transitions  including  the  lack  of  clear  funding  for  “transition,  the  cultural  differences 
between  S&T  and  program  acquisition  communities  which  drive  disparate  goals  and  timelines,  and 
the  fact  that  Transition  processes  lack  clear  definition  and  visibility  by  either  S&T  or  the  Program 
Office.  C2RPC  has  forged  the  partnership  between  ONR  and  PMW-150  to  overcome  these 
impediments,  establishing  shared  expectations  and  addressing  their  respective  budgets.  It  is  critical 
during  this  transition  phase  that  the  S&T  funded  prototypes  achieve  the  expected  maturity  level 
planned  for  by  the  MTC2  sponsor  prior  to  entering  the  transition  phase.  Conversely,  the  Program 
Office  needs  to  have  established  the  necessary  program  plan,  schedule,  and  funding  needed  to 
complete  the  software  development,  testing,  integration  and  ultimate  fielding.  The  program  plan  is 
generated  based,  in  a  large  part,  upon  a  specific  set  of  assumptions  and  risks  and  the  expected 
transition  readiness  of  the  C2RPC  technology.  If  the  C2RPC  capabilities  do  not  meet  the  minimum 
expected,  the  transition  could  fail  leaving  the  MTC2  program  in  jeopardy. 

C2RPC  has  a  Technology  Transition  Plan  (TTP)  Level  A  with  the  MTC2  POR  and  a  start  date  of 
2013.  The  initial  C2RPC  drop  was  developed  in  approximately  18  months.  Further  “Drops”  are 
planned  at  approximately  four  to  six  month  intervals  until  FY  2012.  The  transition  from  the  Late  Stage 
development  to  the  MTC2  POR  for  selected  capability  components  is  scheduled  to  begin  in  early 
2012  and  will  be  done  in  various  steps.  The  transitional  activities  will  be  under  the  leadership  of 
PMW  150  supported  by  SSC  Pacific  as  part  of  its  Navy  C2  Software  Support  Activity  (SSA)  functions 
and  will  employ  testing  and  integration  processes  established  as  part  of  the  RITE  initiative. 

Configuration  Management  and  Documentation 

The  documentation  identified  for  completion  as  part  of  the  C2RPC  prototype  transition  will  be 
developed  collaboratively  using  a  “Confluence”  wiki.  For  the  development  of  technical  reports, 
Confluence  combines  online  authoring  capabilities  and  tools,  Microsoft  Office  integration  and  the 
potential  of  using  a  plug-in  catalog  to  help  team  members  share  information  effectively.  Additionally, 
although  many  individuals  can  contribute  to  the  document  development,  the  Program  Office  retains 
complete  control  over  who  can  create,  edit,  and  view  and  export  documentation.  During  the 
Prototype  development  and  transition  stages,  it  is  envisioned  that  different  development  teams,  as 
well  as  end-users  and  testing  teams  will  be  asked  to  contribute  to  the  respective  document 
development.  Using  the  Wiki  will  ensure  that  contributors  are  using  the  latest,  up-to-date,  version  of 
each  document  for  better  document  configuration  control.  The  Wiki  will  also  allow  for  periodic 
releases  of  the  documents  and  seamless  editing  as  the  prototypes  evolve  as  part  of  the  transition 
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hardening  development. 

As  the  prototype  continues  to  mature,  required  documentation  is  completed  and  filed  on  the  Wiki 
for  use  by  stakeholders  in  performance  of  their  job  requirements.  The  documents  listed  in  Figure  7 
are  from  MIL-STD  498  Standards,  reference  (i),  whose  purpose  is  to  establish  uniform  requirements 
for  software  development  and  documentation.  The  standard  and  its  Data  Item  Description  (DIDs)  are 
meant  to  be  tailored  for  each  type  of  software  to  which  they  are  applied.  Under  the  RITE  process, 
SSC  Pac  works  with  the  Program  Office  to  tailor  the  specific  standards  that  it  wants  to  invoke  for  each 
specific  contract.  The  POR  will  need  to  work  closely  with  C2RPC  in  order  to  produce  the  following  list 
of  documents  to  make  the  technologies  developed  under  C2RPC  are  transitioned  successfully  to  the 
MTC2. 

•  Software  Requirements  Specification  (SRS).  Specifies  the  requirements  for  a  Computer 
Software  Configuration  Item  (CSCI)  and  the  methods  to  be  used  to  ensure  that  each 
requirement  is  met. 

•  Software  Design  Description  [ SDD ).  Describes  the  design  of  CSCI-wide  design  decisions, 
the  CSCI  architectural  design,  and  the  detailed  design  needed  to  implement  the  software. 

•  Software  Test  Description  (STD}.  Describes  test  preparations,  test  cases,  and  test 
procedures  to  be  used  to  perform  qualification  (transition)  testing  of  a  CSCI  or  software 
system  or  subsystem. 

•  Software  Test  Plan  (STP).  Describes  plan  for  qualification  testing  of  CSCI  and  software 
systems.  Describes  test  environment  to  be  used  for  testing,  identifies  tests  to  be  performed, 
and  provides  schedule  for  test  activities. 

•  Software  Transition  Plan  (STrP).  Identifies  hardware,  software,  and  other  resources  needed 
for  life  cycle  support  of  deliverable  software  and  describes  developer’s  plans  for  transitioning 
deliverable  items  to  the  support  agency  (or  the  Acquirer). 

•  Software  Users  Manual  (SUM}.  Explains  how  to  install  and  use  a  CSCI,  a  group  of  related 
CSCI’s,  or  a  software  system  or  subsystem. 

•  Software  Versions  Description  [ SVD ).  Identifies  and  describes  a  software  version  consisting 
of  one  or  more  CSCIs.  It  is  used  to  release,  track  and  control  software  versions,  which  in  this 
case  is  the  initial  software  release  for  transition  to  the  POR. 


ACRONYMS 

Table  1  lists  key  C2  acronyms  used  in  this  paper. 

Table  1 .  Key  C2  Acronyms 


Acronym 

Definition 

AOR 

Area  of  Responsibility 

C2 

Command  and  Control 

C2IPT 

C2  Independent  Project  Team 

C2RPC 

C2  Rapid  Prototyping  Continuum 

CANES 

Consolidated  Afloat  Networks  and  Enterprise  Services 

CDD 

Capabilities  Development  Document 

CDP 

Capabilities  Development  Plan 

Cl 

Configuration  Item 

CM 

Configuration  Management 

COMPACFLT 

Commander,  Pacific  Fleet 

COP 

Common  Operational  Picture 

CSCI 

Computer  Software  Configuration  Item 
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Acronym 

Definition 

DAG 

Defense  Acquisition  Guide 

DIDs 

Data  Item  Descrition 

DSB 

Defense  Science  Board 

DT 

Development  Test 

ERB 

Engineering  Review  Board 
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Information  &  Intelligence 

IATO 

Interim  Authority  to  Operate 

ICD 

Initial  Capabilities  Document 

IDEs 

Integrated  Development  Environments 

JCIDS 

Joint  Capabilities  Integration  and  Development  System 

JCS 

Joint  Chiefs  of  Staff 

MOCs 

Maritime  Operations  Center 

MTC2 

Maritime  Tactical  C2 

NWP 

Naval  Warfare  Publication 

OLW 

Operational  Level  of  Warfare 

ONR 

Office  of  Naval  Research 

OT 

Operational  Test 

OWF 

Ozone  Widget  Framework 

PEO  C4I 

Program  Executive  Office  Command,  Control,  Communications, 
Computers  and  Intelligence 

PMW  150 

Program  Management  Warfare  Office  for  C2 

POR 

Program  of  Record 

R&D 

Research  and  Development 

RITE 

Rapid  Integration  and  Test  Environment 

S&T 

Science  and  Technology 

SA 

Situational  Awareness 

SDD 

Software  Design  Description 

SMEs 

Subject  Matter  Experts 

SRS 

Software  Requirements  Specification 

SSA 

Software  Support  Activity 

SSC  Pac 

SPAWAR  Systems  Center  Pacific 

STD 

Software  Test  Description 

STP 

Software  Test  Plan 

STrPS 

Software  Transition  Plan 

SUM 

Software  Users  Manual 

SVD 

Software  Version  Document 

TF 

Task  Force 

TG 

Task  Group 

TRL 

Technology  Readiness  Level 

TTP 

Technology  Transition  Plan 

SUMMARY 

C2PRC  is  an  initiative  jointly  funded  by  ONR  and  PEO  C4I  to  develop  new  C2  capability 
components  for  future  maritime  C2  PORs.  The  initiative  is  not  only  supporting  the  implementation  of 
a  new  C2  strategy  focused  around  the  four  functional  pillars  of  the  Operational  Level  of  War  but  has 
also  pioneered  new  prototype  development  and  transition  processes  needed  to  rapidly  develop,  test 
and  field  new  software  technologies.  Uniting  the  various  stakeholders,  C2RPC  has  streamlined  the 
S&T  phases  of  the  acquisition  process,  coupling  emerging  technology  requirements,  development, 
testing  and  integration  phases  into  a  continuous  agile  software  development  model  designed  for  IT- 
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intensive  C2  systems.  C2RPC  is  the  first,  from  the  ground  up,  services  architecture  application  that 
has  been  designed  to  run  on  a  shore  based  "cloud"  infrastructure,  currently  hosted  at  SSC  Pacific,  or 
from  a  new  CANES  infrastructure.  This  provides  the  opportunity  for  C2  and  ISR  to  operate  with  an 
autonomous  afloat  capability  when  needed,  and  ashore  high  performance  computer  and  network 
infrastructure  augmentation  as  available. 

C2RPC  prototypes  have  undergone  an  intensive  development  and  demonstration  process  and 
selected  components  are  expected  to  enter  transition  later  this  year.  The  proof  will  be  in  the  ability  to 
successfully  integrate  the  new  software  into  the  C2  POR  but  the  close  coordination  between  ONR 
and  the  Program  Office  throughout  the  prototype  development  has  reduced  POR  risk  and  should 
allow  the  POR  to  field  the  new  C2  software  earlier  than  would  have  been  possible  following  a 
traditional  acquisition  cycle. 
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Information  Dominance 
Anytime,  Anywhere... 


PEOC4l.NAVY.MIL 


Introduction 


*  Navy  undergoing  Command  and  Control  (C2) 
transformation  to  meet  expanding  mission  requirements 

*  “Cloud”  infrastructure  and  capability-related 
applications  will  allow  Navy  organizations  to  reconfigure 
to  meet  dynamic  operational  environments 

*  Transformation  has  2  inter-related  drivers: 


>  A  new  C2  strategy 

-  Based  upon  new  paradyme  for  Maritime  Operations  the  Operational 
Level  of  War  (OLW) 

>  A  new  acquisition  methodology 

-  Links  Science  and  Technology  (S&T)  innovation  with  Navy  C2  Program 
of  Record  (POR)  requirements 

-  Provides  environment  for  rapid  and  agile  C2  software  development,  test, 
integration  and  delivery  of  capabilities  to  the  Fleet 


Agenda 


•  New  C2  Strategy 

>  Current  C2  Situation 

>  New  component  portfolio  approach 

>  Functional  C2  Pillars 

•  New  C2  Software  Acquisition  Approach 

>  Changing  S&T  and  POR  relationship 

>  Command  and  Control  Rapid  Prototyping 
Continuum  (C2RPC)  initiative 

>  Rapid  Integration  and  Test  Environment 
(RITE)  processes  and  infrastructure 


3 


Current  C2  Situation: 

Disconnected  islands  of  C2  data 


MIPS 


NAW  TACTICS,  TECHNIQUES.  Ahib  i^ftflCECUftES 


Planning 


MARITIME  OPERATIONS 
CENTER 
MTTF  3-32.1 


cnmoM  octcgc«?  ?:■][ 


JFMCC  Supporting 
Plan 


To  JTF  Counterstrike 
PLAN  ALFA 


A 


i  mi  ilium  111 1 


Monitoring 


(SA) 


GCCS  (COP) 


Executing 


Assessing 


PowerPoint  slides 


Outlook  .PST  files 


'  Qli 

j:;;  ‘ 

-  Jfc  t-A- 

J/ADOCS 

(Fires) 


- 

14 

ISs- 

c 

s 

"5-_. . 

TBMCS 

(ATO) 


Chat/DCO  windows  Exce,  Spreadsheets 


C2  Strategy  Objectives 


•  Provide  Expanded  Mission  Management 

Capabilities 

>  Add  “What”.  “When”.  “Why”,  and  “How”  to  currently 
provided  “Who”  and  “Where”  information 

>  Needed  to  fulfill  NWP  3-32  and  NWP  5-01*  requirements 

•  Transition  from  Stove-Pipe  Solutions  to  Net- 

Centric  Operations 

>  Implement  “component  portfolio”  approach  to  C2  system 
development 

>  Use  rapid  prototyping  and  technology  insertion  to  speed 
change  and  engage  warfighter 


*  Naval  Warfare  Publication  (NWP)  5-01:  Navy  Planning 

*  NWP  3-32:  Maritime  Operations  at  the  Operational  Level  of  War 


Navy  Doctrine  Demands  an  Integrated  C2 
Planning,  Execution,  &  Assessment  Process 


PLANNING  C2P/r°^mT°IReC°rd 

(POR)  Today: 
“Tracks  on  a  Map” 


EXECUTION 


Navy  Planning  Process 


"Areas  of  Control " 


NWP  5-01  Navy  Planning 


NWP  3-32  Maritime  Operations 
at  the  Operational  Level  of  War 
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Navy  Doctrine  Demands  an  Integrated  C2 
Planning,  Execution,  &  Assessment  Process 


Command 
Relationships 

Maritime 
COA  Analysis 


PLANNING 


EXECUTION 


Lines  of  Operations 
Decision  Points 


Readiness  & 
Apportion¬ 
ment 


ROEs 

PPRs/CASOPs 


Navy  Planning  Process 


"Areas  of  Control 


NWP  5-01  Navy  Planning 


NWP  3-32  Maritime  Operations 
at  the  Operational  Level  of  War 


Desired  End  State 


Implement  aM  C2  functions  and  process 

Exercise  control  actions  in  aM  six  areas 
of  control 


N AVT  TACTICS,  TECrtlOUES.  AM}  PROCEDURES 


mtuciw 


MARITIME  OPERATIONS 
CENTER 
NTTP  3-32.1 

ejmcw  ocrceEP  ecs 
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© 


MARITIME  OPERATIONS  AT 
THE  OPERATIONAL  LEVEL 
OF  WAR 
NWP  3-32 


MW  WARFARE  PUENUCATlOh 


VY  PLANNING 
NWP  S-G1 


Joint  Publication  3-57 


Civil-Military  Operations 


K\  08  July  2008  f: 

V  ir. 


Monitor 
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MOC  (JTF) 


MOC  (CMOC) 


Task  Forces 


Task  Groups  /  CSG 


Task  Units  /  WC 


Task  Elements  /  Units 


Aircraft  & 

Autonomous  Systems 


Pillars  of  Future  C2  system 


Intelligence  &  CM 


ISR  Data  Fusion 


•  13 

•  Analysis  products  &  IPOE 

•  Red  Force  Service 

-  Units/Sites  &  Capabilities 

-  Enemy  COAs  intelligence  & 

-  NAI  Characteristics 

-  Targets 

•  Info  Req’s 

•  Collection  Req’s 


Collection  Mgmt 
Pillar 


Intel  I 
“drill-  >- 
down” 


Cross-Pillar 
Conditions  of  Interest 


ISR  Data 
Fusion 
Pillar 


RAA//B 
tracks 
}  “ drill - 

{___  down” 


Planning- 

Execution. 

Assessment 


*  Conditions  of  Interest  Alerts 

-  Area  entry 

-  task  execution  deviations 

-  (others  TBD) 

*  OTM  (new  track  mgr) 

*  Associate  13  info  w/ 

OTM  reporting 


Planning,  Execution 
&  Assessment 
Pillar 


e.g.,  unit  assigned  to 
task  is  not  ready 


Resources 
“ drill¬ 
down” 


Force,  Unit,  Network, 
Capabilities  &  Readiness 
Pillar 


Capabilities 

&  Readiness 


Plans/Tasks  &  Data  Service 

-  Unit  tasking  &  task  status 

-  Authoritative  plans  data 

Planning 

-  Mission  management 

-  Decision  Points,  LOO 

-  CMD  relationships,  COA  sketch 
Execution 

-  synchronization 


Blue  Force  Service 

-  Units  data  (Admin,  Op) 

-  Platf’s/Systems  Capab 

-  Networks  Config 

Readiness  COP 

-  Platforms/Systems  Status 

-  NetOps  Status 

Capabilities 
Conditions  of  Interest 
Heuristics  &  Alerts 

-  Plan/task  readiness 
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Acquisition  Objectives 


*  Establish  Government  Management  and  Governance  of 
IT  Software  Acquisition  Processes 

>  Implement  agile  IT  acquisition  and  Test  &  Evaluation  (T&E) 
processes  “modeled  on  successful  commercial  practices  for  the 
rapid  acquisition  and  continuous  upgrades  and  improvement  of  IT 
systems.”  (National  Defense  Acquisition  Act  of  FY2010) 

>  Execute  agile  performance-based  contracting  strategy  by  reducing 
vendor’s  “Institutional  Knowledge  Lock” 

>  Synchronize  Government  testing  with  private-industry  development 
-  testing  early  and  often 

*  Establish  methodology  that  takes  advantage  of  Navy 
S&T  innovation  and  successfully  transitions  it  to  Navy 
C2  programs  of  record 
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2  Rapid  Prototyping  Continuum  (C2RPC 

Migrating  to  Maturity 


Coalition  of  PEO  C4I,  Office  of  Naval  Research  (ONR),  and 
Commander  Pacific  Fleet  (COMPACFLT)  , 


•  Develop  a  C2  Prototype  that  Feeds  Back  into  Enduring,  Supported 
Programs  Of  Record 

•  Accelerate  Development  of  OLW  C2  CONOPS 


>  COMPACFLT:  “Use  PACFLT  as  a  ‘Petri  Dish 


>  Advance  the  State  of  the  Art  of  C2 
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-  Reduce  Uncertainty 


>  Ensure  Systems  Meet  Fleet  Prioritized  Capabilities/Needs 


Bringing  S&T  community  and  C2  acquisition  together 

as  one  continuous  program 
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Technology  Maturation  and  Funding 

Bridge 


Science  and  Technology 
Research  & 
Development 


Mission  Capability  Gap 
Identification  and 
Prioritization 


Science  &  Technology 

War  Gaming 

Modeling  and  Simulation 

Map  to  operational  gaps 

TRL  1-2 

TRL  1-2 

S&T  ‘Push’ 

C2RPC 


TRL  6-9 


T 


Laboratory  Experimentation 
TRL  3-8 


Operational  Experimentation 
TRL  6-8 


Valley 
of  Death 


v. 


#  S&T’s  job  is  complete  at  the  tech  dev  stage 
Acquisition  Perceptions  .  |mpiementation  of  technology  is  the 
of  S&T  Community  customer’s  responsibility 

•  “Role  of  S&T  is  tech  push-  build  it  and  they 
will  come” 

•  Develop  cycle  for  S&T  is  too  long  for  most 
acquisition  and  Warfighter  (Customers) 

•  Lack  of  understanding  on  level  of  effort  to 
transition  technology 


POR  ‘Pull’ 

MTC2 


Program  of  Record 
TRL  8-9 


DT/OT  Process 


C2  Release 
Distribution 


_  ..  •  Transition  process  lacks  definition  and  visibility 

Transition  Impediments  .  Djfferent  goa|s  &  tjme|ines  between  S&T  and 

Acquisition  Mgrs 

•  Lack  of  incentives 

•  No  clear  guidance  during  development  from  POR 


12 


Bridging  the  Transition  Valley  of  Death 


Continuum 

>  Organizational 

-  Relationships 

-  Cultural  Change 

-  Communication 

-  POR  Guidance 

>  Technical  Innovation 

>  Funding 


Transition  Impediments 

>  Transition  process  lacks 
definition  and  visibility 

>  Different  goals  &  timelines 
between  S&T  and 
Acquisition  Mgrs 

>  Lack  of  incentives 

>  No  clear  guidance  during 
development  from  POR 


Implementation 

>  Processes 

-  Incremental 
development 

-  Experimentation/Demo 
s/LTEs 

-  Frequent,  early  & 
automated  testing 

>  Infrastructure 

-  Centralized  develop 
repository 


RITE:  Rapid  Integration  and  Test  Environment 
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Rapid  Integration  and  Test  Environment  (RITE) 

‘Foundational  Pillars’ 


RITE  addresses 
findings  and 
facilitates 
development  and 
distribution  of  Navy 
C2  systems: 


▼  Check  -software 
development 

▼Stabilize  -  the 
current  build 

▼  Influence  -  the 
final  product 
delivery 


“Manage  as  close 
to  the  source,  as 
possible” 


+■»  •  Govt  responsible 
for  non- 
2  functional 
‘requirements 
E  definition 
O 

o  •“Govt  Purpose 
Rights”  or 
“unlimited 
Rights”  for  s/w 
(include  source 
code) 

•Drives 

CDRLs/DIDs/CP 
ARS  deliverables 

•Aligns 

Developers  and 
Testers 


RITE  PILLARS 


^  •  Puts  increased 
X  effort  into  early 
0)  stages  of  PLC 

q  'Integrates  “early” 
q  and  “frequent” 
testing  into 
Q_  Development 
stage 

•Requires  regular 
engineering 
drops  of  software 

•Institutionalize 
source  code 
analysis 

•Automates  and 
focuses  testing 

•Standardizes 
tools  and  test 
cases  for 
Developers  and 
Testers 


2  ‘Centralized 

3  Repository- 

enhances  project 

2*  communication 
^  and  collaboration 

(/)  ‘Create 
CO  Framework  for: 

£  ‘Software 
—  Distribution/App 
s  Store 

•Documentation 

Library 

•Development 

•Software 
Testing  tools 
and  data 

•Centralized 

software 

Configuration 

Management 


q  ‘Establish 
■—  Governance 
(g  Plan  based 

|sj  upon  community 

process 

AS 

m  •Rebuilds  Govt 
j-  in-house  S/W 
O  SME’s  to  LEAD 
and  WORK  “as 
peers”  with 
Private  Industry 

•  Establishes  S/W 
career  pipeline 
(Software 
focused  vs. 
operationally 
focused) 
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IT  Acquisition  Life  Cycle 
Alignment 


Rapid  Integration  and  Testing  Environment  (RITE) 
Supports  ALL  phases  of  IT  Acquisition 
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Incremental  Functionality  Leads  to  C2  POR 


S&T Prototyping  Continuum  -  Vision  to  Transition 


Multi-MOC 


Drop  1 
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Apps 
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Data 
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Enterprise 

Services 

abstraction 


Baseline 


•  OTM 


•  R/W  Objects 
in  HaloCOP 


•  HaloCOP  Demo 
of  Task  Icons 


•  CPF  Readiness 
Pilot  (OP LAN 
Readiness) 

•  Multiple 
Readiness  Feeds 


•  HaloCOP, 
selected  data 
mgmt  services 


Drop  4 


Readiness  and 
MOC  Tools 

•Track  Mgmt 
Widgets  -  Initial 
Capability 

•  (13  Red  Force 
Objects  in  COP) 

•  IPOE  Assoc 
w/Plans 


•  Task  Navigator 
(Task  Drill-Down 
from  HaloCOP) 

•  Decision  Point, 
SOP  &  Cmd 
Relationships 

•  CPF  Readiness 
Pilot  (Priority 
Missions  Readi¬ 
ness)  w/PTDS 

•  Navy  Blue 

•  UFS  APIs  & 
WebTop 


Enhanced 
Readiness  and 
MOC  Tools 

•  White  Force  Svc, 

•  Navy  Blue  Force 
mov’ t  (WebSked), 
Environmental 
Conditions/Wx 


•  Targets 

•  IPOE  Integr’  n 
with  Maritime 
COA  Sketch 


•  COA  Sketch, 
Line  of  Ops 
Tools  First  Look 

•  COA  Collabo¬ 
ration 


•  Additional 
Readiness 
Heuristics 

•  Additional 
Mission  Areas 


•  Collaborative 
COP  Initial 
Capability 

•  AIF  Prototype 


Operations 


•  Navy  Blue  Force 
mov’ t  (OTSR) 

•  OTM  Link  & 
Acoustic  T racks 


•  Initial  Link  of 
CCIRs  to  Plans 
&  Decis  Points 


•  Maritime  COA 
Sketch/LOO  & 
Decision  Pts 

•  Ops  Sync  tool 
(Sync  Matrix) 

•  Distributed 
Planning  Among 
MOCs  &  TF/TGs 


•  Readiness 
Integrated 
with  Planning 
Processes  & 
Tools 


•  Initial  AIF 
Capability 
(Ashore,  Afloat) 

•  UFS  Process 
Workflow 
Support 


Capability 
cut-off  and 
transition 
to  C2  POR 


Drop  1 
(MARIO) 


Drop  2 
(SEP10) 


Drop  3* 
(JUL11) 


Drop  4* 
(N0V11) 
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iPhone™  Analogy 

for  Navy  C2  Software  Distribution 


Intelligence  & 
Collection  Mgmt 
Pillar 


IO/ISR/ME 
TOC 
App 
Store 


ISR  Data 
Fusion 
Pillar 


C2  Mission 
Management 
App 
Store 


Plans,  Execution  & 
Assessment  Pillar 


Force,  Unit,  Net, 
Capabilities  &  Readiness 
Pillar 


Afloat  Core  Services  and  Infrastructure 

Software 

CANES  Network  Hardware 
Satellite  Communications 
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Reconfigurable  Navy  C2  Distribution 

Possible  Scenario 


Operational  Commander 

Assigns  new  Tactical  Mission  (e.g.  Civil-Military;  Counter¬ 
drug;  humanitarian  relief,  etc)  to  LCS-1 

•  Designates  additional  Navy  C2  capability  applications  needed  to 
conduct  new  operations  and  to  inter-operate  with  other  tactical 
forces 

•  Provides  ‘authorization  code’  to  download  needed  C2  Apps 


C2  Mission  Management 

Applications  Store 

1  C2  SW  component  catalog 

1  Incremental  engineering 
drops  (developer  builds) 

1  Automated  Test  Tools 

1  FAQs,  Guidance,  Mil-STDs 

'  Requirements,  Best 
Practices,  and  Lesson’s 
Learned 

1  Codes  Sample 


Navy  C2  Software  Support  Activity  (SSC  Pac) 

•  Maintains  Apps  Store  and  Active  Fleet  configuration 
Management 

•  Interfaces  with  OPCON  to  identify  specific  “components” 
(app/version/release)  for  assigned  unit 

•  Conducts  interoperability  and  compatibility  testing  prior  to 
releasing  new  components,  as  necessary 

•  Assigns  ‘Authorization  Code’  for  selected  Components 

•  Releases  new  components  for  designated  unit 


USS  Freedom  (LCS  -  1 ) 


Operational  Unit 

•  Upon  new  assignment  notification  and  Mission  Package 
Update  authorization  -  logs  into  Apps  Store 

•  Using  authorization  code  is  able  to  access  Apps  Catalog  that 
pertains  to  specific  unit 

•  Downloads  new  Mission  Package  components 

•  Runs  automated  acceptance  test  and  installs  into  C2  Core 
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Summary 


•  C2  implementing  a  new  strategy  to  expand  beyond  Situational  Awareness  to 
assist  in  full  spectrum  of  C2,  and  to  address  changes  in  Mission  requirements 

•  C2RPC  is  an  ONR  and  PEO  C4I  Partnership  to  improve  development  strategy 
and  infuse  new  technology  into  future  C2  systems 

>  Provides  insertion  path  for  POR  expectation  and  guidance  to  S&T  prototyping 

>  Coordinates  various  funding  sources  to  bridge  the  valley  of  death 

>  Supports  open  communication  between  all  stakeholders 

>  Establishes  continuous  interaction  with  Fleet  to  understand  operational  needs  and 
validate  prototype  solutions 

>  Accelerates  the  transition  of  User-Validated  C2  capabilities  into  POR 

•  RITE  provides  assured  integration  of  the  technologies  to  meet  cost,  schedule 
&  performance 


>  C2RPC  is  the  first,  from-the-ground-up,  services  architecture  application  designed 
to  run  on  a  shore  based  "cloud"  infrastructure  or  from  new  Consolidated  Afloat 
Network  Enterprise  Services  (CANES)  infrastructure. 

>  Establishes  C2  autonomous  afloat  capability  (when  needed)  AND  ashore  high 
performance  computer  and  network  infrastructure  augmentation  when  available 


Acronyms 


Acronym 

Definition 

Acronym 

Definition 

AIF 

Architecture  Infrastructure  Framework 

HADR 

Humanitarian  Assistance  and  Disaster  Relief 

AMW 

Air  Mobility  Wing 
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Integrated  Imagery  and  Intelligence 

ASW 

Anti-Submarine  Warfare 

10 

Information  Operations 

ATO 

Air  Tactical  Order 

IPOE 

Intelligence  Preparation  of  the  Operational  Environment 

BMD 

Battle  Management  Development 

ISR 

Intelligence,  Surveillance  and  Reconnaissance 

C2 

Command  and  Control 

JCIDS 

Joint  Capabilities  Integration  Development  System 

C2RPC 

C2  Rapid  Prototyping  Continuum 

JFMCC 

Joint  Forces  Maritime  Command  Center 

CANES 

Consolidated  Afloat  Network  Enterprise 
System 

JOPES 

Joint  Operation  Planning  and  Execution  System 

CCIR 

Commander’s  Critical  Information 
Requirements 

JP 

Joint  Publication 

CM 

Configuration  Management 

JTF 

Joint  Task  Force 

CMD 

Cruise  Missile  Defense 

LCS 

Littoral  Combat  Ship 

COA 

Course  of  Action 

MIO 

Maritime  Interdiction  Operations 

COP 

Common  Operational  Picture 

MIW 

Mine  Warfare 

CPF 

Commander  Pacific  Fleet 

MOC 

Maritime  Operation  Center 

DIL 

Disconnected,  Intermittent  and  Limited 

MSO 

Maritime  Security  Operations 

DT 

Development  Test 

MTC2 

Maritime  Tactical  C2 

GCCS 

Global  Command  and  Control  System 

NTTP 

Naval  Technical  Training  Program 
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Acronyms  (continued) 


Acronym 

Definition 

Acronym 

Definition 

OLW 

Operational  Level  s  of  War 

S&T 

Science  and  Technology 

OPCON 

Operational  Control 

SOP 

Standard  Operating  Procedures 

OT 

Operational  Test 

SSA 

Software  Support  Activity 

OTM 

Operational  Track  Management 

SSC 

Space  and  Naval  Warfare  System  Command  (SPAWAR) 
Systems  Center 

PEO  C4I 

Program  Executive  Office  Command, 
Control,  Communications,  Computers, 
and  Intelligence 

T&E 

Test  and  Evaluation 

PMW150 

Program  Warfare  Office  Command  and 
Control 

TBMCS 

Theater  Battle  Management  Core  System 

POR 

Program  of  Record 

TF/TG 

Task  Force/Task  Group 

PPR 

Pre-Planned  Response 

TLAM 

Tomahawk  Land  Attack  Missile 

PTD 

Plans,  Tasks  and  Data  Services 

TRL 

Technology  Readiness  Levels 

RITE 

Rapid  Integration  and  Test  Environment 

UFS 

User  Facing  Service 

ROE 

Rules  of  Engagement 

USW 

Undersea  Warfare 
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Contact  Information 


Patrick  Garcia 

Technical  Director 

Command  and  Control  Systems 
PMW-150,  PEO  C4I 
(619)  221-7273 

patrick.garcia@naw.mil 
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